[アップデート] CloudWatch でクロスアカウントアラームが使用可能に！

ちゃだいん（@chazuke4649）です。

Amazon CloudWatch でクロスアカウントアラームが使用可能になりました！

Announcing Amazon CloudWatch cross account alarms

Amazon CloudWatchは、クロスアカウントアラームを発表しました。これは、お客様がアラートを設定し、他のAWSアカウントのメトリクスの変更に基づいてアクションを実行できるようにする新機能です。クロスアカウントアラームは、さまざまなAWSアカウントの指標の傾向に基づいてアラートを提供し、既存のクロスアカウントダッシュボードと組み合わせて使用​​して、集中型モニタリングアカウントの運用の可視性を設定できます。クロスアカウントアラームでは、異なるAWSアカウントでトレンドとなっている指標が、運用上の問題を引き起こしたり、エンドユーザーの体験に影響を与えたりする前に、さらなる調査が必要であることを示している場合に、アラートを受け取ることができます。

何が嬉しいの？

マルチアカウント構成の場合に、監視用のAWSアカウントにアラームを集中管理することができます。

これまでのCloudWatchのマルチアカウント対応について振り返ります。これまですでにCloudWatchはマルチアカウントに対応しており、共有元アカウントのCloudWatchダッシュボード、メトリクス、アラートを参照することができました。アラートについては既存の共有元アカウントに存在する設定は見れましたが、あくまでかくAWSアカウント単位で設定する必要がありました。今回のアップデートで、共有先アカウント（モニタリングアカウント）側で、共有元アカウント（本番環境アカウントなど）のメトリクスに対しアラートを設定・通知できるようになりました。

これまでの状況については以下ブログがわかりやすいです。

やってみた

実際にやってみます。

基本的には以下公式ドキュメントに従います。

Cross-account cross-Region CloudWatch console - Amazon CloudWatch

1.２つのアカウントを連携させる（両アカウントで作業）

111111111111が222222222222をモニタリングできるように設定します。（「2222222222のメトリクスやダッシュボードを111111111111へ共有する」と同義です）

• 共有先AWSアカウント（モニタリングアカウント）: 111111111111
• 共有元AWSアカウント（本番環境アカウント等）: 222222222222

詳細な手順は以下ブログで紹介されているので割愛します。

設定が完了すると、モニタリングアカウント側で本番環境アカウント側で設定したダッシュボードを参照することができます。

2.アラームを設定する（モニタリングアカウント側のみ作業）

モニタリングアカウント側でアラームを設定します。

1.の連携が完了していると、メトリクスの選択時に本番環境アカウントのEC2メトリクスが選択できるようになっています。ここで、立ち上げておいたEC2インスタンスのCPU使用率を選択します。

メトリクスと条件設定で、本番環境アカウント、インスタンスIDを確認できます。また、「このアラームは別のアカウントのメトリクスが含まれています」と表示されていることで、クロスアカウントアラームを設定していることがわかります。

条件はシンプルに、CPU使用率が50を超えたらアラート状態になるようにします。

アクションは、アラート状態になったらSNS経由でメールを飛ばします。

以上で設定は完了しました。アラート設定が作成されているかどうか確認しようとすると、

あれ？　アラート一覧に作成したアラートがありません。

かなり些細なハマりポイントで、表示されない理由は上部データ表示箇所で「本番環境アカウント（222222222222）」が選択されているためです。

ここをモニタリングアカウント（111111111111,Local Account)に変更します。

先ほど作成したアラートを確認することができました。よかったよかった。

3.アラーム通知をテストする

本番環境アカウント側で、立ち上げておいたEC2インスタンスに負荷をかけCPU使用率を上げてみます。

[ec2-user@ip-172-31-24-25 ~]$ yes > /dev/null &
[1] 32127
[ec2-user@ip-172-31-24-25 ~]$ jobs
[1]+  実行中               yes > /dev/null &
[ec2-user@ip-172-31-24-25 ~]$ top
top - 04:28:47 up 36 min,  1 user,  load average: 0.80, 0.33, 0.12
Tasks:  86 total,   2 running,  48 sleeping,   0 stopped,   0 zombie
%Cpu(s): 98.7 us,  1.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  1006892 total,   414556 free,   100636 used,   491700 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   763316 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
32127 ec2-user  20   0  114636    756    696 R 99.9  0.1   1:28.30 yes
    1 root      20   0  125556   5492   4016 S  0.0  0.5   0:01.95 systemd
    2 root      20   0       0      0      0 S  0.0  0.0   0:00.00 kthreadd
    4 root       0 -20       0      0      0 I  0.0  0.0   0:00.00 kworker/0:0H
    5 root      20   0       0      0      0 I  0.0  0.0   0:00.04 kworker/u30:0
    6 root       0 -20       0      0      0 I  0.0  0.0   0:00.00 mm_percpu_wq
    7 root      20   0       0      0      0 S  0.0  0.0   0:00.13 ksoftirqd/0
    8 root      20   0       0      0      0 I  0.0  0.0   0:00.19 rcu_sched

少し待ってみてアラームをコンソールから確認すると、以下の通りステータスがアラーム状態に変更されました。

以下の通りメールも通知されました。

アラームの詳細はモニタリングアカウントであり、メトリックは本番環境アカウントの対象インスタンスIDであることが確認できました。

検証は以上です。

終わりに

CloudWatchによるマルチアカウント監視運用がまた１つやりやすくなりました。マルチアカウント戦略である以上、できる部分はとにかく全て集中一元管理していき、管理効率を上げていきたいですね。

それではこの辺で。ちゃだいん（@chazuke4649）でした。